Flusing log uart during fault #6660
Conversation
When system fault is occured, The system is in the irq locking state, The logs that have not yet been output remain in the uart buffer and are not output. So, For debugging, it is necessary to flush the log uart buffer before outputting the fault log. For flushing transmit buffe, we need to know xmit buffer is empty or not. Therefore, Add to so that uart_xmitchars function returns amount sent. the return value is 0, xmit buffer is empty. Signed-off-by: eunwoo.nam <[email protected]>
ewoodev
force-pushed
the
WORK-250206_flush_log_uart
branch
7 times, most recently
from
4ed0553 to
fef47cc
Compare
|
|
||
| /* To avoid duplicated calling up_flush_console(). */ | ||
| if (g_log_flush_running) { | ||
| return; |
There was a problem hiding this comment.
we should have leave_critical_section here.
There was a problem hiding this comment.
Thank you, Updated!
…ault log. since, The system fault is occured, uart log is stil in the uart buffer and not printed. So, we can't see last log. Therefore, Add flusing log uart buffer when fault is occured. Signed-off-by: eunwoo.nam <[email protected]>
ewoodev
force-pushed
the
WORK-250206_flush_log_uart
branch
from
fef47cc to
9e0b6b9
Compare
| do { | ||
| while (!LOGUART_Ready()); | ||
| nbyte = uart_xmitchars(&CONSOLE_DEV); | ||
| } while (nbyte); |
There was a problem hiding this comment.
How does this work? Currently it looks like we still rely on uart interrupts to send data. But interrupts are disabled. Wont it be better to use lldbg path instead?
There was a problem hiding this comment.
The IRQ is calling uart_xmitchars()
There was a problem hiding this comment.
I meant uart_xmitchars path is through drivers (will call the drivers send function and it also has some signalling logic to wakeup other threads), but at this point, we are no longer using the driver's path to print logs. Instead we use lldbg, so I asked the above question, why not use up_putc instead of driver send.
No description provided.